home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 1478 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.8 KB  |  108 lines
  1. Newsgroups: comp.lang.c
  2. Path: gail.ripco.com!mambuhl
  3. From: mambuhl@ripco.com (Martin Ambuhl)
  4. Subject: Re: Need Help compiling M
  5. X-Nntp-Posting-Host: golden.ripco.com
  6. Message-ID: <DL62Bz.4uJ@rci.ripco.com>
  7. Sender: usenet@rci.ripco.com (Net News Admin)
  8. Organization: Ripco Internet BBS Chicago
  9. Date: Sun, 14 Jan 1996 10:26:22 GMT
  10. X-Ident-Sender: mambuhl
  11.  
  12. "Thomas J. Hruska" <71524.2020@compuserve.com>
  13. in <4d8aph$9it@dub-news-svc-5.compuserve.com> asks:
  14.  
  15. >Does anyone know how in the world to compile Microsoft C code using a
  16. >Borland C/C++ compiler?!?!?  I couldn't make heads or tails of what the
  17. >stupid manual said...
  18.  
  19. 0) It is commonly held that compiler-specific problems do not belong in
  20. comp.lang.c, but usually in a system-specific newsgroup (e.g.
  21. comp.os.msdos.programmer).  While I usually agree with this view,
  22. porting questions have two characteristics that make me provide an
  23. answer for this question.  First, porting is something that C
  24. programmers must often do, and usually the only people you can ask are
  25. other C programmers.  This is obviously more true when the port is
  26. cross-platform, rather than cross-compiler on the same platform as here.
  27. Second, many of the problems which are run into for a particular port
  28. have some generalizability.  I hope some of the following is useful.
  29.  
  30. 1) Most of the code should be ANSI C, and that part should port without
  31. problems.  The code which is not ANSI C should -- as far as possible --
  32. be converted to standard C before you do anything else.
  33.  
  34. 2) Historically, there have been a number of implementation-dependent
  35. library functions with different names (and parameter lists and return
  36. values) in Microsoft and Borland implementations.  Borland has tried to
  37. provide implementations of the MS form.  For example, you will find
  38.  
  39.     unsigned _dos_findnext(struct find_t *ffblk);   /* MS call */
  40.     int findnext(struct ffblk *ffblk);  /* Borland call */
  41.  
  42. The Borland implementation has long provided both forms, so no problems
  43. arise with the MS->Borland port.  None the less, the parts of your code
  44. using such implementation-specific code should be separated as much as
  45. possible into implementation-specific files, and every effort should be
  46. made to make it easily changed if you should want to port the code to
  47. some other compiler (say gcc) or environment (say a unix variant, Linux
  48. or FreeBSD for example) or machine (say DEC Alpha, Sun, etc.).
  49.  
  50. The rule is: if several functions may provide the functionality you
  51. need, prefer them in this order (see the library docs):
  52.     a) The ANSI C function (Your implementation should provide this).
  53.     b) The UNIX (or POSIX) function that your implementation provides.
  54.     c) The function which your implementation (Borland) and the
  55.     source implementation (MS) both provide.
  56.     d) The your-implementation(Borland)-only function
  57.  
  58. 3) Unless you have become very familiar with make, do not bother trying
  59. to learn how to convert MS makefiles to Borland makefiles.  They both
  60. differ substantially from more common versions of make.  Do as much as
  61. possible with the IDE.  You will want to become comfortable with make in
  62. the long run, of course.
  63.  
  64. 4) Rather than set the environment variables LIB and INCLUDE, change the
  65. default paths in the IDE.  If you stick to the IDE, you needn't worry
  66. about differences in the command-line switches either.  You will, of
  67. course, ultimately want to become intimate with the command-line
  68. version.
  69.  
  70. 5) If your code uses the non-standard <dos.h> header,
  71.     #define __MSC   /* before #include <dos.h> */
  72.    so the DOSERROR structure will match MS's.
  73.  
  74.     For the following non-standard headers, either name should work:
  75.     <dir.h> | <dirent.h>
  76.     <mem.h> | <memory.h>    /* BUT: consider <string.h> */
  77.  
  78.     Replace any #includes of either <alloc.h> or <malloc.h> with the
  79.     standard <stdlib.h>.  If this makes a change in the code necessary
  80.     (unlikely), make the change.
  81.  
  82. 6) If the code contains these keywords, you will have problems. These
  83. are non-standard and the code should be rewritten (if possible) to
  84. exclude them:
  85.  
  86.     MS-keyword:  possible BCC/TCC-cure:
  87.     _based      #define _based
  88.     _self       #define _self
  89.     _segname    #define _segname
  90.     _segment    #define _segment _seg
  91.     _emit       #define _emit(x) __emit__(x)
  92.     _fortran    #define _fortran _pascal
  93.  
  94. 7) You may have problems with floating point or structure return values.
  95.   If so, call Borland Technical Support.
  96.  
  97. 8) Do _not_ use bitfields or depend on wordsize or rely on alignment of
  98. members in structs or unions.  Do _not_ use the words "far", "near",
  99. "pascal", "interrupt" and similar things in the body of your code.  Use
  100. macros like
  101.     #define FAR far
  102. which you can later change (in a rational environement) to
  103.     #define FAR
  104.                                                                              
  105. --
  106. * Martin Ambuhl       net: mambuhl@ripco.com
  107. * Chicago, IL (USA)    
  108.